User selectable securable device

ABSTRACT

The principles of the present invention provide for a more flexible kiosk securable device system and method that enables users to select their own securable device, such as a locker, rather than having the kiosk assign one to them. In selecting a securable device, the user enters the same access indicia (e.g., PIN) that he or she entered in the kiosk into any available securable device, and, in response to the kiosk or securable device verifying that access indicia, the selected securable device may be provisioned to the access indicia in accordance with rental parameter(s), such as rental duration, size of securable device, and so forth.

RELATED APPLICATIONS

This application claims priority to co-pending U.S. ProvisionalApplication Ser. No. 61/808,523 filed Apr. 4, 2013, the contents ofwhich are hereby incorporated by reference in their entirety.

BACKGROUND

Rental securable devices, such as lockers at amusement parks and skislopes, were historically coin operated. A couple of problems havetraditionally existed with coin operated lockers, including people nothaving quarters and people simply using the lockers without paying forthem as a result of coin operated lockers having to be unlocked beforecoins are deposited and a key being removed from the locker.

More recently, for efficiency and informational purposes, banks ofsecurable devices or locker systems rentable via a kiosk were developed.As understood in the art, these locker systems provide for one or morecentrally configured kiosks to enable a user to interface with a singleor multiple points to pay for and rent a securable device or locker. Inrenting a locker through such a conventional kiosk, a user submits apersonal identification number (PIN) and the kiosk assigns a locker forthe user and communicates the submitted PIN to the assigned locker,thereby enabling only that user to have access to that assigned locker.The user also sets the rental time for that locker at the kiosk.

SUMMARY

The principles of the present invention provide for a more flexiblekiosk securable device system that enables users to select their ownsecurable device, such as a locker, rather than having the kiosk assignone to them. By allowing users to select their own securable device atthe physical securable devices themselves, users can (i) select asecurable device that is conveniently located instead of being computerassigned, (ii) select a securable device at a height that is convenientfor a user, which is particularly helpful for disabled users, (iii)select a securable device that is away from congestion of other users atthe time of selection, (iv) select a securable device that is easy toremember, and (v) start the rental period at a delayed start time asdesired by the user. In selecting a securable device, the user entersthe same access indicia (e.g., PIN) that he or she entered in the kioskinto any available securable device, the securable device communicatingthe access indicia to the kiosk, and, in response to the kiosk orsecurable device verifying the received access indicia, the kiosk mayprovision the selected securable device by associating and storing anidentifier of the selected securable device with the access indicia inaccordance with rental parameter(s), such as rental duration, size ofsecurable device, and so forth.

One embodiment of a method for provisioning a securable device mayinclude providing a controller user interface to enable a user toinitiate access of a securable device from a set of securable devices inlocal communication with the controller user interface. The user may beenabled, via the controller user interface, to submit an access indiciafor accessing one of the securable devices from the set of securabledevices. In response to receiving the access indicia, the access indiciamay be stored independent of any particular securable device identifierassociated with the set of securable devices by a controller computingdevice in communication with the controller user interface. In responseto receiving (i) the access indicia from the user interfacing with asecurable device user interface associated with a selected securabledevice and (ii) a securable device identifier via a communicationsmedium, the access indicia received from the selected securable devicematches the stored access indicia may be verified. In response toverifying a match, the securable device identifier and the accessindicia may be associated by the controller computing device so as toprovision the selected securable device for the user. A verificationsignal indicative of the access indicia received from the selectedsecurable device matching the stored access indicia may be communicatedto the securable device controller. The securable device controller mayprovision the securable device. Otherwise, in response to the accessindicia received from the securable device not matching the storedaccess indicia, the user may be prevented from accessing the securabledevice.

Another embodiment of a system for provisioning a securable device mayinclude a set of securable devices and a set of securable devicecontrollers, where each of the securable devices includes a securabledevice controller. A controller user interface may be in communicationvia a communications medium with the set of securable devicecontrollers, and be configured to enable a user to (i) initiate accessof a securable device from the set of securable devices and (ii) enablethe user to submit an access indicia to access any one of the securabledevices from the set of securable devices. A controller computing devicemay be in communication with the controller user interface, and beconfigured to (i) store, in response to receiving the access indicia,the access indicia independent of any particular securable deviceidentifier associated with the set of securable devices and (ii)communicate, via a communications network, the access indicia to each ofthe securable device controllers in the set of securable devicecontrollers. A selected one of the securable devices with an associatedsecurable device controller may be configured to (i) in response toreceiving an entered access indicia from the user at the selectedsecurable device, verify that the entered access indicia matches theaccess indicia, (ii) in response to verifying that the entered accessindicia matches the access indicia, enable entry of the selectedsecurable device, otherwise, not enable entry of the selected securabledevice, and (iii) communicate the access indicia and a securable deviceidentifier associated with the selected securable device via thecommunications medium to the controller computing device to provisionthe selected securable device thereby.

BRIEF DESCRIPTION

Illustrative embodiments of the present invention are described indetail below with reference to the attached drawing figures, which areincorporated by reference herein and wherein:

FIG. 1 is an illustration of an illustrative locker system that includesa kiosk that enables a user to pay for, access, and provision lockers inaccordance with the principles of the present invention;

FIG. 2 is an illustration of an illustrative keypad that provides a userinterface for a user to access a locker of FIG. 1;

FIG. 3 is an illustration of an illustrative network environment inwhich a kiosk/controller may communicate with securable devicecontrollers/locks in accordance with the principles of the presentinvention;

FIG. 4 is an illustration of illustrative tables for use in provisioningsecurable devices and establishing undesignated rentals or accessindicia for use of the securable devices;

FIG. 5 is an interactive diagram of an illustrative process that enablesusers to select their own securable device at the physical securabledevices in accordance with the principles of the present invention;

FIG. 6 is a screenshot of an illustrative user interface provided on akiosk that enables a user to rent a locker in accordance with theprinciples of the present invention;

FIG. 7 is a screenshot of an illustrative user interface that enables auser to select a payment method for renting a securable device orlocker;

FIG. 8 is a screenshot of an illustrative user interface at a kiosk thatenables a renter of a securable device to enter an access indicia (e.g.,personal identification number (PIN));

FIG. 9 is an illustration of an illustrative keypad on a locker in whichthe renter may use to select and access a locker by entering his or heraccess indicia as entered into a kiosk;

FIG. 10 is an illustration of an illustrative amusement park where usersmay select lockers throughout the amusement park in accordance with theprinciples of the present invention;

FIGS. 11A and 11B (collectively FIG. 11) is an interaction diagram of anillustrative process that enables a user to select any locker at thephysical lockers themselves throughout a geographic region, such as anamusement park;

FIG. 12 is a screenshot of an illustrative graphical user interface thatmay be used as an initial user rental screen at a kiosk or controller ata securable device station;

FIG. 13 is a screen shot of an illustrative graphical user interfacethat allows a user to enter a 7-digit customer ID into a kiosk forrenting securable devices;

FIG. 14 is a screen shot of an illustrative graphical user interfacethat allows a user to enter a 4-digit access code or indicia into akiosk for renting securable devices;

FIG. 15 is a screen shot of a graphical user interface to confirm with auser attempting to switch portable securable devices whether or not toend a currently rented securable device;

FIG. 16 is a screen shot of a graphical user interface to display amessage that lists a locker number assigned to the user, rentalexpiration time, and selected rental type (e.g., single use locker); and

FIG. 17 is a block diagram of illustrative software modules forexecution on a controller or kiosk that enables a user to select his orher own locker and rent and/or select a locker within a geographicregion or multiple geographic regions (e.g., different amusement parksor ski slope resorts).

DETAILED DESCRIPTION OF THE DRAWINGS Select Your Own Locker

With regard to FIG. 1, an illustration of an illustrative locker system100 may include a locker bank 102 in which different sized lockers 102a-102 m and 102 n-102 z (collectively 102) are available for people torent. It should be understood that the lockers 102 may alternatively allbe the same size. Each of the lockers 102 may include locks 104 a-104 z(collectively 104) that are inclusive of a user interface (e.g., keypad)and electromechanical lock mechanism, as understood in the art.Associated with the locker bank 102 is a kiosk 106 with which people mayuse to interface in renting the lockers 102. The kiosk 106 may include ascreen 108 that may display locker rental options. In one embodiment,the screen 108 is a touchscreen that enables the user to touch to makeselections for renting a locker. Alternative configurations of a userinterface, such as hard-buttons, may be utilized in accordance with theprinciples of the present invention. To make a payment for the rental ofa locker, payment options 110 may provide for a renter to enter a card(e.g., credit card or debit card), pay by bills, pay by coins, use ascanner to scan a ticket, image on a mobile device, or otherwise, or payusing near field communications (NFC) via a mobile device or otherwise.Alternative payment techniques may be provided, as well. A securabledevice includes a locker, but is not limited to a locker as other formsof securable devices, such as ski locking mechanisms to lock skis on anoutdoor ski rack at a ski slope, may be utilized in accordance with theprinciples of the present invention.

With regard to the scanner, the scanner may be a barcode reader, quickreference (QR) code reader, magnetic strip reader, camera, or anycombination or other scanner as understood in the art to read an indiciaon a ticket, mobile device, receipt, coupon, or other medium usable toprovide the kiosk 106 with payment credit or instructions (e.g., seasonlocker payment amount, daily discount, etc.). For example, in oneembodiment, the user may purchase a season ticket that also includes aseason locker rental. The season locker rental may be a multiple of thecost of a daily rental, such as three times the cost of a daily rental,that may provide the user with certain access throughout a season, suchas one lock/unlock per day per visit, unlimited unlocks per day, and soforth. To make the purchase, the user may purchase the seasonal lockerrental from the amusement park and scan a purchase code or indicia(e.g., barcode) at a kiosk of the lockers, thereby initiating the user'sseasonal rental. The QR code, if purchased via a mobile app or onlinevia a website, may be communicated to and displayable on a mobile deviceand can be scanned by the scanner on the kiosk. In one embodiment, thekiosk may be in communication with the park's data system, often knownas a park “folio” system (i.e., data system used to monitor seasonalticket holders), and confirm the purchase of the seasonal locker rentalprior to initiating the user's seasonal locker rental. The scannerfunctionality and payment options may be utilized for any rental option(e.g., “select your own,” “assigned locker,” “portable locker,” etc.)described herein.

In accordance with the principles of the present invention, the kiosk106 may communicate with the locks 104 to notify the locks 104 that auser has selected or been assigned a particular lock or that the userhas elected a “select your own locker” option that enables a user toenter his or her access indicia, such as a personal identificationnumber (PIN), into any available locker (i.e., a lock 104 a of a locker102 a) that meets a criteria, such as small locker and/or large locker,that he or she chooses, as further described herein. A communicationchannel 112 between the kiosk 106 and the locks 104 of the lockers 102may be hardwired or wireless databus, and communications may include anaddress for a particular lock 104 or a broadcast message that isreceived by all of the locks 104. The communication channel 112 maysupport any communications protocol, as understood in the art. Thecommunication may include access indicia (e.g., personal identification,number) and, optionally, rental parameter(s) in a distributed systemconfiguration or be a communication back to the kiosk from a lock orsecurable device controller to verify valid access indicia of the system100 is configured in a centralized system configuration, as furtherdescribed herein.

With regard to FIG. 2, an illustration of keypad 104 a is shown toinclude numeric keys 202, “enter” key 204, and “end usage” key 206. An“occupied” visual indicator 208, such as an LED, may also be associatedwith the keypad of the lock 104 a. In one embodiment, the keys 202, 204,and 206 are hard-buttons that the user presses to interface with thekiosk 106. Alternatively, a touchscreen electronic display withsoft-buttons may be utilized. Additional indicators, such as a “PIN notrecognized” indicator in the form of a light and/or audio signal (notshown), may additionally and/or alternatively be provided in associationwith the lock 104 a.

With regard to FIG. 3, an illustrative network environment in which akiosk 302 may be utilized by a user to rent a securable device is shown.The kiosk 302 may include a processing unit 304 that executes software306 that configures the processing unit 304 to perform certain functionsin accordance with the principles of the present invention. Theprocessing unit 304 may be in communication with a memory 308,input/output unit 310, and storage unit 312. The storage unit 312 mayinclude one or more data repositories 314 a-314 m (collectively 314).The processing unit 304 may further be in communication with userinterface 316 that includes a payment unit 318. The software 306 mayoperate in conjunction with each of the other components, includingproviding functionality that supports the user interface 316 to assistin renting securable devices (e.g., lockers). These data repositories314 may include information in association with each rental and eachsecurable device, such as interactions with each securable device byusers who have rented the securable devices. The payment unit 318 may beconfigured to accept payment (e.g., cash, credit, debit, scanning ofreceipt, ticket, mobile device) for rental of securable devices. Thesoftware 306 may be configured to assign a securable device to a user,enable a user to select his or her own securable device at a bank ofsecurable devices local (i.e., within a local proximity and/or localcommunication of the kiosk 302) to the kiosk 302, and/or remotelypositioned from the kiosk 302 and that may be associated with anotherkiosk (not shown).

Multiple securable devices, such as lockers, may include a securabledevice controller/lock 320 a-320 n (collectively 320) that are incommunication with the kiosk/controller 302. The securable devicecontroller/lock 320 a may be a “smart lock” and include a processor 322that executes software 324 that is used to control operation of thesecurable device controller/lock 320 a. The lock 320 a may furtherinclude a memory 326 that is used to store data and software,input/output unit 328, user interface 330, and lock 332. Theinput/output unit 328 may be configured to communicate data over anetwork 334 with the kiosk/controller 302. The user interface 330 may bethat shown in FIG. 2 or be an alternative user interface that enables auser to enter his or her PIN or access indicia (e.g., fingerprint). Insuch an embodiment, the controller 302 may communicate a PIN to the lock320 a via the network 334 for storage in the memory 326. In oneembodiment, the software 324 may be configured to receive a PIN from theuser interface 330 and compare the PIN with PINs stored in the memory326, and, if the PIN matches one of the PINs in the memory 326, then thelock 332 may be caused to open by the processor 322. If the PIN does notmatch any PIN stored in the memory 326, then the software 324 mayprevent the lock 332 from being opened. As a result of the securabledevice controller/lock 320 a including a processor 322, the securabledevice controller/lock 320 a may operate autonomously after receiving anaccess indicia, thereby being immune from power failure or communicationfailure with the kiosk/controller 302. The network 334 may be a localarea network (LAN), hardwired network, wireless network, wide areanetwork (WAN), or any other communications network, as understood in theart.

As further shown in FIG. 3, the kiosk/controller 302 may be incommunication with park server(s) 336 that are configured to manage apark's data, such as season ticket holder data and point-of-sale (POS)data. The kiosk/controller 300 may be configured to receive, request,and communicate data with the park server(s) 336 to confirm lockerrental purchases via a ticket booth of the park, seasonal ticket and/orlocker rental purchases, online rental purchases of lockers, and so on.

With regard to FIG. 4, an illustration of illustrative data repositories400, including a provisioned securable devices data repository 402 andan established, unprovisioned rentals data repository 404. Theprovisioned securable devices data repository 402 may include a numberof data parameters, including securable device identifier, accessindicia (e.g., PIN, RFID tag, scannable code, etc.), valid indiciacondition(s), and user interactions with securable device. The accessindicia may be a four digit indicia. Alternatively, other numbers ofdigits, such as seven, may be utilized. Still yet, the access indiciamay be an alphanumeric value. Alternatively, the access indicia may be abiometric identifier (e.g., fingerprint or swipe of a user's finger),for example. The valid indicia condition(s) may include a variety ofdifferent valid conditions, such as the securable device being rentedall day, over a limited period of time (e.g., 2:00 pm-5:00 pm), alimited time period starting from a locker selection time (e.g., 2 hoursfrom locker selection) over a limited geographic area, local to a kiosk,a combination thereof, or otherwise. The conditions may be listed in ahuman-readable form, but machine readable information or information inother formats (e.g., all parks=p1-p4), for example. The userinteractions with a securable device may include a historical listing ofwhen an associated securable device is accessed by a user. Allinteractions may be captured and stored.

In accordance with the principles of the present invention, datarepository 404 may be configured to store data of established,unprovisioned rentals. That is, the content stored in the datarepository 404 is not yet associated or provisioned with any securabledevice. As shown, the data repository 404 may include a number of dataparameters, including access indicia, valid indicia condition(s), andpurchase date/time. The valid indicia condition(s) may include a timerange (e.g., hours of accessibility, duration of accessibility fromfirst locker access), date range, number of locks that a user can accesssecurable devices in a certain geographic area, and time and date thatthe user has purchased the accessibility to any available securabledevice. The securable devices may also be specified based on size, suchas small locker or large locker, and location, such as locker in park A,locker in any of parks A-N, locker at particular ride (e.g.,rollercoaster), or otherwise.

Because the users have requested to have an undesignated or unassignedlocker, the data stored in data repository 404 may be, at least in part,be communicated to securable devices that meet the criteria of theselected securable devices (e.g., time range, location, size) orutilized by the kiosk to compare when new access indicia are receivedfrom securable devices. That is, any securable device that meets rentalparameter(s) and receives a valid access indicia may be provisioned orassigned with that access indicia. For example, in response to a userwith access indicia “5250” entering that access indicia into a securabledevice controller of a securable device, the securable devicecontroller, if the established unprovisioned rental data has beendownloaded thereto, may vary of the access indicia and indiciacondition(s) or communicate received access indicia to the kiosk forconfirmation thereat prior to providing access to the securable device.Although not shown, a user identifier may be associated with the accessindicia, thereby allowing the user to change his or her access indiciain different rental periods, and the system to track and use historicalinformation of the user.

With regard to FIG. 5, an interaction diagram of an illustrative process500 that enables a user or renter of a securable device to select his orher own securable device, as opposed to the kiosk assigning a securabledevice, is provided. A central controller 502 operating as or within akiosk may communicate with securable device controllers 504 a-504 n(collectively 504). The securable device controllers 504 may beassociated with respective securable devices that are local or inimmediate proximity of the central controller 502 (e.g., under the sameroof or conspicuously near the kiosk).

The process 500 may start at step 508, where a user interface isprovided by the central controller 502. The user interface may be agraphical user interface on a touchscreen, graphical user interface withhard-buttons associated with the graphical user interface for selectionof user options, hard-buttons not on a graphical user interface, orotherwise, as understood in the art. At step 510, the central controller502 may receive a user initiated request for a securable deviceincluding request parameters. The request parameters may include type oflocker, size of locker, location(s) of locker, duration of rental,access indicia, payment, etc. At step 512, the central controller 502may store access indicia and request parameters independent of asecurable device identifier (e.g., locker number or identifier). Thestored access indicia and request parameters are established,unprovisioned at this point and remain unprovisioned until the userenters the access indicia into a securable device associated with one ofthe securable device controllers 504. Such a configuration allows forusers to delay start time for rental periods. The storage may be in adata repository, such as those shown in FIG. 4.

At step 514, an optional step, as indicated by dashed lines, ofcommunicating the access indicia and parameter(s) may be communicated tothe securable device controllers 504. That is, because the userrequested to use a user selection process for one of the securabledevices, the indicia and parameter(s) are communicated to the securabledevice controllers 504 so that the securable device controllers 504 mayperform their own verification of an access indicia submitted into oneof the securable devices by a user. In such a decentralizedverification, provisioning of a selected securable device by the centralcontroller 502 thereafter or a centralized verification of the accessindicia may be performed in addition to the decentralized verification(i.e., both the securable device controller and central controller 502may perform a verification of an entered access indicia).

If step 514 is performed, then at step 516, the securable devicecontroller 504 a stores the access indicia and associated parameters. Atstep 518, a user interface may be provided to a user. In one embodiment,the user interface may be a keypad, as provided in FIG. 2, for example.Alternative user interfaces may be provided at the securable devices, aswell. At step 520, the securable device controller 504 a may receive anaccess indicia from a user who is selecting his or her own securabledevice at a physical securable device. At step 522, if the accessindicia parameter(s) are communicated to the securable device controller504 a at step 514, then the securable device controller 504 a may verifythe access indicia. In verifying the access indicia, the securabledevice controller 504 a may verify (i) that the access indicia matchesan access indicia (e.g., PIN) or has a match likelihood above athreshold if using biometrics, for example, of an access indicia beingstored by the controller 504 a and that the parameters (e.g., date,time, time frame, location number of times of using locks, etc.) arevalid. Steps 524-530 performed by securable device controller 504 n maybe identical to the steps 516-522 performed by securable devicecontroller 504 a.

At step 532, in the event that step 514 is not performed, where thesecurable device controllers 504 are provided the access indicia andparameter(s) as is performed in a distributed system configuration, theaccess indicia entered into a selected one of the securable devicecontrollers 504 and associated securable device identifier arecommunicated back to the central controller 502 for verificationthereat. At step 534, the central controller 502 may verify the accessindicia 534 received from the selected securable device controller. Thisconfiguration is a centralized configuration, as opposed to adecentralized or distributed configuration where the securable devicecontrollers 504 perform the verification step. As shown, the dashed-linesteps are for the decentralized configuration. At step 536, the centralcontroller 502 may associate or compare the access indicia and securabledevice identifier to established, unprovisioned rentals in an effort toprovision a securable device. In other words, in response to a userentering his or her access indicia into a securable device, the centralcontroller 502 will provision or assign the user-selected securabledevice to be in association with the access indicia.

At step 538, the central controller 502 may communicate an accessindicia verification to the securable device controller 504 a. At step540, usage of the securable device may be enabled for the user by thesecurable device controller 504 a by unlocking the securable device orotherwise recognizing that the securable device is being utilized by theuser. If, at step 534, the access indicia is not verified, then thecentral controller 502 may not associate the access indicia andsecurable device identifier so as to not provision the securable device,and a provision rejection signal may be communicated at step 538 to thesecurable device controller 504 a to prevent the user from accessing theassociated securable device. At step 542, the securable devicecontroller 504 a may communicate any further interactions by the userwith the securable device controller 504 a (i.e., locking, unlocking,entered access indicia, or otherwise).

With regard to FIG. 6, a screenshot of an illustrative user interface600 is provided. The user interface 600 may include a number ofdifferent selectable parameters, including duration of rental 602,provisioning type 604, locker size 606, and locations of lockers 608.The duration for rental section 602 may include a single lock (i.e.,lock the locker one time and the rental is complete), multiple locks foradditional cost, two hours fixed time of locker rental unlimited locks,half day rental with an unlimited number of locks (i.e., in-and-outs ofa locker), or all day rental with an unlimited number of locks. Theprovisioning section allows the user (i) to have a locker assigned tohim or her by the kiosk or (ii) to select their own locker, where theuser may select any qualifying locker by entering his or her indicia atany locker or any type or class of lockers (e.g., small or large). Thelocker size selection option 606 may include a small locker for a firstcharge (e.g., no additional charge) or a large locker for an additionalcharge (e.g., $1.00 additional).

It should be understood that the locker options may include different oradditional options and may vary based on park type, locker types, or anyother configuration of securable devices or system configurations. As anexample, the user may be able to purchase rental of ride-only lockersthat are meant for small items, such as mobile devices, for no or somecharge ($1.00), for multi-ride only locker usage. If all large lockersare currently provisioned, then the system may prevent such a rental orprovide notice that all large lockers are currently provisioned andallow for a large locker rental and allow the user to access smalllockers and large lockers when one becomes available. In one embodiment,a “family or friends rental” option may be provided, where a certainnumber of simultaneous rentals, such as four large lockers, using thesame or different access indicia may be performed to reduce the amountof time needed at the kiosk by related people. The location section 608allows the user to select a locker based on location of the lockers,such as a locker bank associated with the kiosk, a locker bank anywherewithin a facility (e.g., ski lodge), at a particular ride (e.g., TornadoAlley coaster), at a particular park section (e.g., Fantasy Place), at aparticular park (e.g., Dinosaur Park), all parks, or otherwise. A totaldue amount field 610 may tabulate a total amount due by the user for theselected options.

With regard to FIG. 7, a screen shot of an illustrative user interface700 for enabling a user to select a payment method for rental of asecurable device is shown. The user interface may include a number ofdifferent payment options, including debit 702 a, credit 702 b, Paypal®702 c, cash 702 d, or prepaid scan 702 e. It should be understood thatany other form of payment may be included, such as using a near fieldcommunication (NFC) payment method via a smart phone (e.g., ewallet). Inaddition, the user interface may allow for promotional discounts,coupons, or other cost-offsetting discounts to be entered via scanningor text entry. Other possible payment systems may be utilized, includingcoins, private point-of-sale systems of amusement parks (e.g., DisneyDollars®) or ski resorts, for example, coupons, Internet or ticket boothpre-purchase codes, and so on. In one embodiment, a location in whichthe lockers are operating, such as an amusement park, may allow forusers to purchase locker rentals while paying for passes into thelocation (e.g., amusement park day or multi-day pass). In such anembodiment, the park pass or entry ticket, which may include a codeprinted on the entry ticket or computer readable medium, such as amagnetic strip or RFID tag, on the entry ticket may include informationthat can be read by the kiosk, central controller, secondary controller,or securable device controller.

The human or machine readable information may enable the user to haveaccess to a securable device, thereby allowing the system to provision asecurable device for the user without having pay money in any form at akiosk or otherwise. That is, the user simply presents or scans theticket at the local controller (e.g., kiosk) and the system reads andconfirms payment information and handles the provisioning as if the userpaid at the kiosk using another form of payment. Alternative means ofpayment may be made, such as (i) using a hotel room key with paymentinformation for a securable device, (ii) text messaging a payment code,(iii) entering a coupon code (e.g., 8 digit alphanumeric code), (iv)submitting a prepaid code to a text message address that, if confirmed,is communicated to a central controller to establish payment, (v)imaging or scanning an indicia, such as a bar code or QR code, andmessaging or uploading that imaged indicia to an online address orlocally at a kiosk, (vi) presenting a machine readable code, such as aprepaid purchase code, on a ticket or coupon to a bar code scanner orcamera at the kiosk, and (vii) so on. In one embodiment, rather thanscanning, the kiosk may include a text message or other communicationsprotocol processing capability so as to receive and process anelectronic message sent by a user that includes a code, indicia, orotherwise that allows the kiosk to receive, confirm, or charge forpayment.

With regard to FIG. 8, an illustration of an illustrative user interface800 to enable a user to enter an access indicia, such as a PIN, that maybe operated on a kiosk is shown. The user interface 800 may display ageneral representation of a keypad 802 that is used on securabledevices. Alternative keypad representations may be utilized, such as atouch-tone telephone keypad. As shown, the keypad 802 may include, butnot limited to, numeric keys 804. After the user has entered his or heraccess indicia, the user may select an “enter” soft-button 806. If theuser makes a mistake in entering the access indicia, then the user mayselect the “clear” soft-button 808. It should be understood that if thesecurable devices include a different input device, such as a touch pad,biometric reader device, or otherwise, that the different input devicemay be represented in the user interface 800 or made available at thekiosk (e.g., biometric reader device) rather than the keypad. As shown,a “fingerprint” soft-button 804 a and “phone NFC” soft-button 804 b maybe made available if either of those input devices are made available atthe securable device.

With regard to FIG. 9, an illustration of an illustrative user interface900 of a physical securable device is shown. The user interface mayinclude a keypad 902 that includes digits, an “enter” button 904 tosubmit an entered PIN, and an “end usage” button 906 when the user hascompleted using the securable device. Alternative configurations of thekeypad 902 may be utilized, such as one that does not include an “enter”key if all PINS are required to be a certain number of digits, such asfour digits. In addition to the keypad 902, the user interface 900 mayalso include a visual indicator 908 to show that the securable device iscurrently occupied and visual indicator(s) 910 to show that a PIN thatis entered is valid or invalid. It should be understood that the userinterface 900 may be mechanical in nature, as shown, or be displayed onan electronic display. Additionally and/or alternatively, biometricreader devices, NFC reader devices, scanners, or any other input devicesthat may assist in identifying a user who has rented a particular lockeror any available locker through a “select your own locker” option may beutilized in accordance with the principles of the present invention.Other identification options that are possible, include, but are notlimited to, barcode scanning, imaging, QR code scanning, machinereadable code scanning, keyfob reading, key usage, magnetic strip cardreading, Internet communication via smart phone or tablet, Near FieldCommunication (NFC) via smart phone or device, or any other technique.

Portable Locker

With regard to FIG. 10, an illustration of an illustrative amusementpark 1000 is shown. The amusement park 1000 may include a number ofdifferent sections, including section 1002 a, 1002 b, 1002 c, and 1002 d(collectively 1002). Each of the different sections may have a differenttheme, as understood in the art. As people who attend amusement parksare well aware, traveling between the different sections of an amusementpark can be very time consuming, especially with children. As such,people who visit amusement parks and have valuables or other items ofwhich they wish to store, tend to store those items in lockers that arecentral or conveniently located near the front of the park. However, bystoring items in lockers near the front of the park, to retrieve thoseitems during the day, the user is inconvenienced. As a result, peopleavoid renting lockers and, thus, have to carry their valuables or otheritems with them, thereby reducing their enjoyment and overallsatisfaction with their park experience.

Another problem that amusement parks have tried to solve over the yearsproviding adequate and safe storage of items at rides on which peoplegenerally need to leave their valuables, such as sunglasses, wallets,prizes, mobile devices, and other items due to high speeds, invertedpositions, water exposure, etc., of the rides. In some cases, thosesolutions are bins positioned at the ride itself. This solution,however, is insecure and many different people that are entering andexiting different cars or vehicles (e.g., boats) often have access tothe items of others who are on the rides. With people carrying mobiledevices, this solution is relatively unacceptable to people. As aresult, an alternative, safe solution that includes a securable deviceis desired.

As shown in FIG. 10, the amusement park 1000 includes an entranceway1004 through which visitors of the amusement park 1000 may enter. Twobanks or sets of securable devices 1006 a and 1006 b (collectively 1006)are located close to the entranceway 1004. The two banks of securabledevices 1006 may have kiosks 1008 a and 1008 b (collectively 1008)available for visitors to rent securable devices either at theentranceway 1004 or elsewhere throughout the park 1000, as furtherdescribed herein. The combined banks of securable devices 1006 andkiosks 1008 are considered to be a securable device station. Aspreviously described, the kiosks 1008 may be configured to enable a userto rent a securable device that is associated with the kiosk(s) 1008,such as any of the securable devices 1006. In such a rental, the kiosks1008 may be configured to enable the user to have the kiosk assign oneof the securable devices 1006 to the user. Alternatively, the user mayenter a PIN, for example, into the kiosk and then select one of thesecurable devices 1006 by entering the same PIN in any of the availablesecurable devices 1006 that conforms to rental parameters (e.g., smallor large securable device). In response to the user's entering a validPIN in one of the securable devices 1006, the selected securable devicemay be provisioned as being occupied by associating a securable deviceidentifier with the PIN.

As further shown in the park, a number of different securable devicestations inclusive of banks of securable devices and kiosks 1010 a-1010q (collectively 1010) are available. To avoid limiting users to a lockersystem in which the user initially rents a securable device, theprinciples of the present invention may provide for a user with a rentaloption that enables utilization of any securable device at a particularride (e.g., Ferris Wheel) or location (e.g., food court), in one of thesections 1002 of the park 1000, within the entire park 1000, or evenwithin multiple parks (e.g., various related or unrelated theme parks inOrlando) over a time frame (e.g., one or multi-day time span). Inproviding such an option, a central controller, which may or may not bepart of one of the kiosks associated with any of the securable devicestations 1006 or 1010 shown in FIG. 10, may receive all rental ordersand communicate access indicia and rental parameter(s) to each of thesecurable device controllers that meet the conditions of the rentalparameter(s). Alternatively, a central controller may receive accessindicia submitted at the securable devices and determine whether or notthe access indicia is valid for the associated securable devices bydetermining whether the access indicia meets the purchased rentalparameter(s), such as one that allows for selecting a locker, one forselecting a locker at a particular time of day, and one for selecting alocker in a certain section in the park 1000.

As another example, the park 1000 may have different types of securabledevices, such as those that are large and located along walking pathsand those that are small and located at loading points of a ride. Theuser may elect to purchase an option that allows for use of one or bothtypes of securable devices. The user may also elect to purchase anoption that allows for use of both types simultaneously so that the usermay use a larger securable device to store larger items, while alsoallowing the user to use a small securable device to store smalleritems, such as sunglasses, keys, mobile phone, wallet, etc., whenparticipating on a ride. To employ these options, either a central ordistributed network and controller configuration may be utilized, wherea central configuration has a central system (e.g., server) receivingrequests from each of the securable devices or their associated kiosks,if utilized, receive and verify access indicia and rental parameter(s),while a distributed configuration may have each of the local kiosks orsecurable device controllers handle verifying access indicia and rentalparameter(s). In the central configuration, the access indicia andrental parameter(s) are not communicated from a central controller(e.g., kiosk) to securable device controllers, while the distributedconfiguration communicates the access indicia and rental parameter(s) tothe securable device controllers so that the securable devicecontrollers can operate autonomously from the central controller. Acentral configuration may be “cloud” based or a server may operate on alocal network (e.g., at an amusement park).

Fraud detection may also be employed to prevent one person renting asecurable device and providing an access indicia, such as a PIN, toothers for simultaneous use at other securable devices throughout thepark 1000. In a central system, such a fraud detection system wouldverify whether the access indicia is currently in use and deny secondaryrequests for simultaneous usage at different securable devices. However,for a distributed configuration, the access indicia and, optionally,rental parameter(s) would be distributed to other kiosks and/orsecurable device controllers, and any changes to the status of usagewould be distributed to the kiosks and/or securable device controlleralso. Sufficient memory may be provided for each of the distributedkiosks and/or securable device controllers and used to store each of thepossible access indicia and associated rental parameter(s) available foruse at those securable devices.

With regard to FIG. 11, an interactive diagram of an illustrativeprocess that 1100 that enables a user to select any securable device inone or more geographic region(s) and, optionally, of a particular type,is shown. A number of different devices are shown, including a centralcontroller 1102 (e.g., kiosk) and associated securable devicecontrollers 1104 a-1104 n (collectively 1104) that are part of locks onassociated banks of securable devices. A secondary controller 1106 andassociated securable device controllers 1108 a-1108 n (collectively1108) are also provided to enable the user to (i) select his or her ownsecurable device, as opposed to a kiosk or central controller assigninga securable device, (ii) in either of the local or remote banks ofsecurable devices. In this context, the local bank of securable devicesis the bank of securable devices that is locally associated with therespective controllers due to proximity and configuration (e.g.,hardwired and/or local bus). In this example, central controller 1102 islocally associated with securable device controllers 1104 and secondarycontroller is locally associated with securable device controllers 1108.Although not shown, there may be many secondary controllers locallyassociated with banks of securable devices each including a securabledevice controller. Each of the secondary controllers may operate as akiosk that communicate with the local securable controllers to enablepeople to rent those local securable devices. In accordance with theprinciples of the present invention, each of the secondary controllers1106 may enable a user to purchase a rental (i.e., pay for renting asecurable device) that provides for the user to select a local orremotely located securable device by communicating such rentalparameters in association with an access indicia along with rentalparameter(s) to the central controller 1102 and/or to other secondarycontrollers (not shown), as further described hereinbelow.

At step 1110 a, the central controller 1102 may provide a user interfaceto enable a user to rent a locker. The user interface may be the same orsimilar to the one shown in FIG. 6. Because the central and secondarycontrollers 1102 and 1106 operate independent of one another, thesecondary controller 1106 may provide the same or similar interface asthe one being provided by the central controller at step 1110 b. At step1112, a user request may be received and the central controller 1102 maystore an access indicia and rental parameter(s). At step 1114, theaccess indicia and rental parameter(s) may be communicated to thesecondary controller 1106 via a communications network. The accessindicia may operate as a key for the secondary controller to use todetermine whether the user is attempting to access one of the securabledevices associated with the securable device controllers 1108 at somepoint in the future. In one embodiment, the communication of the accessindicia and rental parameter(s) may be performed in response to the usermaking the purchase. Alternatively, since the user cannot travel betweenthe central controller 1102 and secondary controller 1106 very quickly,the central controller may communicate such requests periodically (e.g.,every 5 minutes) or aperiodically (e.g., responsive to the secondarymaking a request for an update in response to not recognizing an accessindicia entered into one of the securable device controllers 1108).

At step 1116, the securable device controller 1104 a may receive anaccess indicia, such as a PIN typed into a keypad, from a user. In acentralized configuration, the access indicia may be communicated atstep 1118 to the central controller 1102 for verification at step 1120.The verification may determine that the access indicia matches a storedaccess indicia along with verifying that other rental parameter(s) aresatisfied (e.g., with a number of locks, within a rental time periodpurchased, within a rental date period purchased, within a size ofsecurable device purchased, for a duration of time starting from a firstuse, or any other rental parameter). As previously described, if adistributed configuration is utilized, where the securable devicecontroller 1104 a is capable of verifying that the access indicia isvalid (i.e., step 1120 may be performed solely by the securable devicecontroller 1104 a rather than central controller 1102), a situation of apower failure disabling usage of the securable devices as a batterybackup may be used by the securable device controllers 1104 and 1108 maybe avoided.

Continuing with the centralized configuration, at step 1122, an accessverification indicator (e.g., Boolean value) may be communicated back tothe securable device controller 1104 from the central controller 1102 toindicate that the access indicia is valid or invalid. At step 1124, inresponse to the access verification indicator being received, thesecurable device controller 1124 may enable or deny access to thesecurable device to the user. A status indicator illumination device oraudible sound may be generated, as well, to alert the user to thesuccess or failure of the attempt to access the securable device. Atstep 1126, the current and further user interactions (e.g., unlocking,opening, closing, ending usage, etc.) with the securable device may becommunicated by the securable device controller 1104 a to the centralcontroller 1102 so that the central controller 1102 may maintain arecord of the interactions, handle provisioning operations, manage andprevent fraudulent usage, and so forth.

At step 1128, status updates associated with the access indicia may becommunicated to the secondary controller 1106 so that the secondarycontroller 1106 may operate independent of the central controller 1102.As an example, if the access indicia has been used to access a securabledevice accessed via the securable device controller 1104 a, then thesame access indicia cannot be used to simultaneously access any of thesecurable devices that are access controlled by the securable devicecontrollers 1108 while the securable device associated with thesecurable device controller 1104 a is being used by the user using theaccess indicia (assuming the user has purchased a rental that includesremotely located securable devices from the central controller 1102).

At step 1130, the securable device controller 1108 a may receive anaccess indicia from the user. In the centralized configuration, thesecondary controller 1106 is central to the securable device controllers1108 and independent from the central controller 1102, the accessindicia may be communicated from the securable device controller to thesecondary controller 1106 at step 1132. The secondary controller 1106may verify the access indicia and, in response, communicate an accessindicia indicator at step 1136 back to the securable device controller1108 a. The securable device controller 1108 a, may, in response toreceiving the indicator, enable or deny access to the user to thesecurable device at step 1138. At step 1140, the securable devicecontroller 1108 a may communicate the current and future userinteractions with the securable device to the secondary controller 1106to manage, provision, and prevent fraud. In response, the status updates1142 may be communicated back to the central controller 1102 formanagement and redistribution purposes to other secondary controllers1106. In an alternative configuration, the secondary controller 1106 maycommunicate the status updates directly with other secondary controllersand/or securable device controllers. The status updates may be performedreal-time, on a period basis, or on an aperiodic basis. As with thesecurable device controllers 1104, the securable device controllers 1108may operate in a distributed configuration such that the controllers1108 may perform verifications of access indicia entered by usersindependent of secondary controller 1106.

Although presented with regard to FIG. 11 that the central controller1102 may collect and manage information from the secondary controller1106 and other secondary controllers, the principles of the presentinvention may alternatively utilize a “cloud” database (e.g., oneaccessible on a LAN or WAN, such as the Internet) that is common to eachof the controllers 1102 and 1106, such that the same or similarmanagement functionality described with respect to the centralcontroller 1102 is positioned on the “cloud” database. Such a “cloud”solution reduces the chances of a communications failure in the eventthe central controller 1102 breaks or loses power as a “cloud” solutionmay also provide for redundancy. In addition, accounting, management,and reporting features may be more easily performed and accessible aslower operation resources of a “cloud” server are used as compared tothe user-facing controllers 1102 and 1106. Other collection, reporting,and management configurations, such as all of the controllers sharingauthorization and/or provisioning information with one another, thatprovide for the same or similar functionality of enabling a user toselect his or her own securable device or have a “portable” securabledevice that is selectable from among any of the securable locker banksmay be utilized.

Furthermore, and as detailed above, users may have the option of asingle use or “portable” securable device, such as a locker, rental,where a single use rental may enable a user to select one securabledevice from all of the securable devices in the independent banks ofsecurable devices in an amusement park, for example. With a “portable”securable device rental, a user may change securable devices during agiven time period as desired because each independent secondarycontroller 1106 has the rental parameter(s) that provide for an “allpark,” “valid park sections,” “multi-park” rental parameter associatedwith the access indicia. With such a configuration, when the user hascompleted using a securable device, the user may press an “end rental”button and a report to a controller 1102 or 1106 is performed tode-provision the access indicia from the associated securable device(e.g., 1104 a or 1108 a). If the user forgets to press the “end rental”button, the system (e.g., secondary kiosk) may notify the user that theprevious securable device is still being rented and ask whether the userwants to end that rental, as further described hereinbelow. Oncede-provisioned, if the access indicia still has available time for usagewith another securable device as specified by the associated rentalparameter(s), then the access indicia and associated rentalparameters(s) may be placed back into or otherwise identified as beingavailable for usage by one or more of the controllers 1102 and 1106 (or“cloud” database). Alternatively, each securable device may beconfigured with a sensor, optical or otherwise, that automaticallydetermines that the securable device is empty and currently unlocked orempty and unlocked for a predetermined period of time and automaticallyde-provisions the securable device. In one configuration, each user mayselect a PIN code, such as a 4-digit PIN code. Alternatively and/oradditionally, each user may have a user identifier, such as a 7-digituser identifier. Other configurations are possible, as well. Forexample, a non-kiosk system may be provided where apps or an Internetavailable website on mobile devices are utilized to interact with a“cloud” database or directly with addressable controllers (e.g.,controllers that control a bank of securable devices or securable devicecontrollers).

Continuing with FIG. 11, in an alternative embodiment, the secondarycontroller 1106 may operate as a “first stop” for a user in accessing a“portable” securable device at a remote securable device station, inthis case including secondary controller 1106 and securable devicesassociated with the securable device controllers 1108, from the centralcontroller 1102. In this configuration, the user engages the secondarycontroller 1106 prior to any of the securable device controllers 1108.At the secondary controller 1106, the user requests a portable locker atstep 1144 by selecting to move his or her portable locker to thatsecurable device station via a user interface of the secondarycontroller 1106. If the secondary controller 1106 has already receivedan access code of the user from the central controller 1102, then theuser may gain access to a securable device associated with the secondarycontroller 1106 without having to re-create and/or re-rent a securabledevice via the secondary controller 1106. In response to the secondarycontroller 1106 receiving the access indicia from the user, thesecondary controller 1106 may verify the access indicia and ensure thatthe user is complying with the parameters of his or her rental (e.g.,within a purchase time limit).

If the secondary controller 1106 determines that the user has purchaseda portable securable device that is available at that securable devicestation, then the access indicia may be communicated to each of thesecurable device controllers 1108 to enable the user to select his orher own securable device, as previously described. Alternatively, thesecondary controller 1106 may be configured to assign a securable devicefor the user and communicate the access indicia to the selectedsecurable device. At step 1148, the securable device controller 1108 amay receive an access indicia from the user, and, in response, (i)determine that the user has access to that securable device and (ii)enable the user to access the securable device by unlocking a lock ofthe securable device. At step 1150, the securable device controller 1108a may communicate the access indicia to the secondary controller 1106,thereby notifying the secondary controller 1106 that the user hasaccessed the securable device controller 1108. It should be understoodthat the access indicia received by the securable device controller 1108a may be communicated to the secondary controller 1106 at step 1150, aswell. The secondary controller 1106 may store information associatedwith the user accessing the securable device controller 1108 a in alocal repository and/or communicate that information remotely to thecentral controller 1102 or elsewhere (e.g., “cloud” server).

As the user further interacts with the securable device controller 1108a, those user interactions may be reported by the securable devicecontroller 1108 a to the secondary controller 1106 at step 1152. Thesecondary controller 1106 may communicate status updates associated withthe accessing the securable device to the central controller 1102 atstep 1154. Alternatively, the status updates may be communicated toanother computing system, such as a “cloud” server. It should beunderstood that a variety of different configurations may be utilized inwhich the secondary controller 1106 may operate as a “first stop” forusers in accessing the securable devices associated with the. securabledevice controllers 1108.

With regard to FIG. 12, a screenshot of an illustrative graphical userinterface 1200 that may be used as an initial user rental screen at akiosk or controller at a securable device station is shown. Thegraphical user interface 1200 may provide for a number of options for auser, including soft-button 1202 that allows a user to rent a single uselocker or securable device at a local securable device station,soft-button 1204 that allows the user to rent a multi-use ride locker,in the case of the kiosk operating in an amusement park or water park,for example, that can move to other locker or securable device stations,soft-button 1206 that allows the user to move his or her multi-use ridelocker to this securable device station from a currently differentsecurable device station, and soft-button 1208 that allows a user toopen an expired locker or securable device. If the user selectssoft-button 1208 to open an expired locker, then the user may berequired to add additional money for excess time beyond the expirationtime that the user has used the securable device. It should beunderstood that the number of selectable options and specific functionsof the options may vary based on an environment in which the securabledevice station(s) are located. For example, if the securable devicestation(s) are located at a ski slope, those options may be associatedwith mountains, lodges, top/bottom of mountain, and so forth.

In addition to the four available selection options, the graphical userinterface 1200 may provide a handicapped soft-button 1210 that alertsthe kiosk or controller that the user is handicapped and to accommodatethe user in making available a securable device that is handicapconfigured. If the kiosk is configured to select a securable device forusers, or at least handicapped users, then the kiosk may select ahandicap-configured securable device. If the user is able to select hisor her own securable device at the kiosk, then the securable devicecontrollers of handicap-configured securable devices may be configuredto allow the user to have access thereto by sending an access indicia ofthe user, for example.

In addition to the functionality available on the graphical userinterface 1200, help soft-buttons 1212 a-1212 d associated withsoft-buttons 1202-1208, respectively, may enable a user to receiveadditional information about each of the functions of the soft-buttons1202-1208. An overall help soft-button 1214 may be provided to enable auser to receive instructions and information of how to use the system,kiosk, and securable devices at the securable device station andenvironment at which the station(s) are located (e.g., amusement park).With regard to FIG. 13, a screen shot of an illustrative graphical userinterface 1300 that allows a user to enter a 7-digit customer ID into akiosk for renting securable devices is shown. The graphical userinterface 1300 provides a soft-keypad 1302 and text field(s) 1304. Auser of the kiosk may type in a 7-digit customer ID, such as a telephonenumber, and the 7-digit customer ID may be displayed in the textfield(s) 1304 so that the user can review prior to submission. The kioskor other management system may use the 7-digit customer ID to verify theuser and to manage the user's usage of securable devices. It should beunderstood that alternative number of digits may be utilized, but that a7-digit customer ID allows for a user to use a telephone number of whichhe or she can easily remember.

With regard to FIG. 14, a screen shot of an illustrative graphical userinterface 1400 that allows a user to enter a 4-digit access code orindicia into a kiosk for renting securable devices is shown. Asoft-keypad 1402 for a user to type the 4-digit access indicia or PIN,and text field(s) 1404 to allow the user to view the access indicia maybe shown on the screen. It should be understood that any other number ofdigits may be used for the access indicia. Moreover, the access indiciamay be a biometric indicia, such as a fingerprint via a fingerprintreader at the kiosk and that can also be read at the securable devices(e.g., one or more fingerprint reader for a bank of securable devices orone fingerprint reader for each securable device). The access indiciaallows for the system to verify the user and securable device code.

With regard to FIG. 15, a screen shot of a graphical user interface 1500to confirm with a user attempting to switch portable securable deviceswhether or not to end a currently rented securable device is shown. If,for example, the user forgets that he or she still has another securabledevice located at the same or another securable device station still inuse, then the kiosk may notify the user by displaying a message 1502,such as “Are you sure you want to end the above rental?” and display anidentifier of the current securable device (e.g., “QA Locker #3”) beingrented. If the user does want to end the current rental, then the usermay press a “confirm” soft-button 1504. Otherwise, if the user does notwant to end the current rental, then the user may press a “cancel”soft-button 1506. If the user ends the existing rental, the associatedcontroller and/or central controller may de-provision the securabledevice to unlock to enable other users to rent that securable device.

With regard to FIG. 16, a screen shot of a graphical user interface 1600to display a message 1602 that lists a locker number assigned to theuser, rental expiration time, and selected rental type (e.g., single uselocker) is shown. Other information may additionally and/oralternatively be displayed. Once complete, the user may press a “finish”soft-button 1604. In one embodiment, the kiosk may be configured toenable a user to submit an electronic address (e.g., mobile devicetelephone number) that allows the kiosk to communicate a messageinclusive of locker number, expiration time, or other information thatmight be helpful to the user in using the securable device system.

With regard to FIG. 17, a block diagram of an illustrative set ofsoftware modules 1700 that may be executed on a central controller,secondary controllers, common “cloud” database, and/or securable devicecontrollers is shown. The software modules 1700 may include a manageuser interface module 1702 that operates to manage a user interface,such as one shown in FIG. 6, to enable users to rent securable devices.A process securable device access transaction module 1704 may beconfigured to receive access requests from securable devices. The accessrequests may be in the form of access indicia being entered into userinterfaces on securable devices. The module 1704 may receive the accessindicia and determine whether the access indicia is valid or invalidbased on rental parameter(s) and provide an indicator to a requestingsecurable device controller. In one embodiment, the verification processmay be performed on a securable device controller.

A communicate with securable device controllers module 1706 may beconfigured to enable a central and/or secondary controller tocommunicate with securable device controllers. The communications may beperformed over a communications link, such as a local area network, widearea network, or other communications network using any communicationsprotocol, as understood in the art.

A manage securable devices data repository module 1708 may be configuredto manage data associated with securable devices. The data may include avariety of different information, such as size, location, status (e.g.,vacant or not vacant, locked or unlocked), usage/access information, orany other information.

A manage access indicia module 1710 may be configured to manage accessindicia, including actual indicia (e.g., PIN, biometric data), date andtime of purchase, rental parameter(s) (e.g., number of times to uselocks purchased, duration of time purchased, dates purchased, geographiclocations (e.g., at particular ride, sections of parks, multiple parks,etc.) purchased, assigned or selectable, or any other rental parameter).

A communicate with other controllers module 1712 may be configured toenable a central and/or secondary controller to communicate with othercontrollers. The module 1712 may be configured to communicate statusupdates, access requests, new access indicia and associated rentalparameter(s), and so on.

A reports module 1714 may be configured to enable a supervisor of thesecurable device system to generate reports, including current orhistorical reports, usage reports, repeat user reports, or any otherreports that help a supervisor manage and operate the securable devicesystem.

A maintenance module 1716 may be configured to assist a supervisor tomaintain the securable device system, including locking or unlockingspecific securable devices, disabling securable devices, operationbuilt-in-self tests of securable devices and controllers, testingcommunication (i) between central and secondary controllers and (ii)between central and secondary controllers with securable devicecontrollers, examine and edit data repositories, or any othermaintenance function in accordance with the principles of the presentinvention.

A park system communication module 1718 may be configured to interfacewith a park computing system that manages data, such as a park'spoint-of-sale (POS) system. As previously provided, the park systemcommunication module 1718 may be in communication with a park's foliodata system that manages season ticket holders who might purchaseseasonal locker rentals.

The previous description is of a preferred embodiment for implementingthe invention, and the scope of the invention should not necessarily belimited by this description. The scope of the present invention isinstead defined by the following claims.

What is claimed:
 1. A method for provisioning a securable device, saidmethod comprising: providing a controller user interface to enable auser to initiate access of a securable device from a set of securabledevices in local communication with the controller user interface;enabling, via the controller user interface, the user to submit anaccess indicia to access any one of the securable devices from the setof securable devices; in response to receiving the access indicia,storing, by a controller computing device in communication with thecontroller user interface, the access indicia independent of anyparticular securable device identifier associated with the set ofsecurable devices; in response to receiving (i) the access indicia fromthe user interfacing with a securable device user interface associatedwith a selected securable device and (ii) a securable device identifiervia a communications medium: verifying that the access indicia receivedfrom the selected securable device matches the stored access indicia; inresponse to verifying a match: associating, by the controller computingdevice, the securable device identifier and the access indicia so as toprovision the selected securable device for the user; communicating averification signal indicative of the access indicia received from theselected securable device matching the stored access indicia to thesecurable device controller; and provisioning, by the securable devicecontroller, the selected securable device; alternatively, in response tothe access indicia received from the securable device not matching thestored access indicia, preventing the user from accessing the selectedsecurable device.
 2. The method according to claim 1, wherein providinga controller user interface to enable a user to initiate access of asecurable device from a set of securable devices includes providing acontroller user interface to enable a user to initiate access of alocker from a set of lockers.
 3. The method according to claim 1,wherein providing a controller user interface includes providing akiosk.
 4. The method according to claim 1, wherein receiving the accessindicia includes receiving data representative of a PIN.
 5. The methodaccording to claim 1, further comprising communicating, by thecontroller computing device via the communications medium, the accessindicia to each securable device computing device associated withrespective securable device user interfaces for storage thereat prior tothe user initiating access of the selected securable device.
 6. Themethod according to claim 1, further comprising establishing, by thecontroller computing device, at least one condition that defines whetherthe access indicia is valid.
 7. The method according to claim 6, whereinestablishing the at least one condition includes establishing acondition that defines geographical locations in which the accessindicia is valid.
 8. The method according to claim 7, whereinestablishing the at least one condition includes establishing acondition that defines a time period during which the access indicia isvalid.
 9. The method according to claim 6, further comprisingcommunicating, by the controller computing device via a communicationsnetwork, the access indicia and the at least one condition to a secondcontroller computing device in communication with the controllercomputing device, the second controller computing device beingconfigured to control provisioning of a second set of securable devices.10. The method according to claim 9, further comprising: receiving, bythe second controller computing device, the access indicia from a secondselected securable device of the second set of securable devices and asecond securable device identifier associated with the second selectedsecurable device; and determining, based on the at least one conditionthat defines whether the access indicia is valid, whether the accessindicia is valid for accessing the second selected securable device ofthe second set of securable devices, and if so, provisioning, by thesecond controller computing device, the second selected securabledevice; otherwise, not provisioning the second selected securabledevice.
 11. The method according to claim 10, further comprising, inresponse to provisioning the second selected securable device,communicating the second securable device identifier to the controllercomputing device for provisioning thereby.
 12. The method according toclaim 10, further comprising in response to receiving the access indiciaand second selected securable device identifier, determining whether theaccess indicia is currently associated with another securable device,and, if so, preventing provisioning of the second selected securabledevice, otherwise, enabling provisioning of the second selectedsecurable device.
 13. A system for provisioning a securable device, saidsystem comprising: a set of securable devices; a controller userinterface in local communication with said set of securable devices, andconfigured to: enable a user to initiate access of a securable devicefrom said set of securable devices; enable the user to submit an accessindicia to access any one of the securable devices from the set ofsecurable devices; and a controller computing device in communicationwith said controller user interface, and configured to: store, inresponse to receiving the access indicia, the access indicia independentof any particular securable device identifier associated with the set ofsecurable devices; in response to receiving (i) the access indicia fromthe user interfacing with a securable device user interface associatedwith a selected securable device and (ii) a securable device identifiervia a communications medium: verify that the access indicia receivedfrom the selected securable device matches the stored access indicia; inresponse to verifying a match: associate the securable device identifierand the access indicia so as to provision the selected securable devicefor the user; communicate a verification signal indicative of the accessindicia received from the selected securable device matching the storedaccess indicia to the securable device controller; and provision theselected securable device; alternatively, in response to the accessindicia received from the securable device not matching the storedaccess indicia, prevent the user from accessing the selected securabledevice.
 14. The system according to claim 13, wherein said controlleruser interface is a kiosk.
 15. The system according to claim 13, whereinsaid controller computing device is further configured to communicatevia the communications medium the access indicia to each securabledevice computing device associated with respective securable device userinterfaces for storage thereat prior to the user initiating access ofthe selected securable device.
 16. The system according to claim 13,wherein said controller computing device is further configured toestablish at least one condition that defines whether the access indiciais valid, the at least one condition including a condition that definesgeographical locations in which the access indicia is valid.
 17. Thesystem according to claim 16, wherein said controller computing deviceis further configured to establish a condition that defines a timeperiod during which the access indicia is valid.
 18. The systemaccording to claim 17, further comprising: a second controller computingdevice in communication with the controller computing device; and asecond set of securable devices, wherein said controller computingdevice is further configured to communicate, via a communicationsnetwork, the access indicia and the at least one condition to saidsecond controller computing device, said second controller computingdevice being configured to control provisioning of said second set ofsecurable devices.
 19. The system according to claim 18, where saidsecond controller computing device is further configured to: receive theaccess indicia from a second selected securable device of said secondset of securable devices and a second securable device identifierassociated with the second selected securable device; and determine,based on the at least one condition that defines whether the accessindicia is valid, whether the access indicia is valid for accessing thesecond selected securable device of said second set of securabledevices, and if so, provision the second selected securable device;otherwise, not provision the second selected securable device.
 20. Thesystem according to claim 19, wherein said second controller computingdevice is further configured to communicate the second securable deviceidentifier to said controller computing device in response toprovisioning the second selected securable device.
 21. The systemaccording to claim 19, wherein said controller computing device isfurther configured to determine whether the access indicia is currentlyassociated with another securable device in response to receiving theaccess indicia and second selected securable device identifier, and, ifso, prevent provisioning of the second selected securable device,otherwise, enable provisioning of the second selected securable device.22. A system for provisioning a securable device, said systemcomprising: a set of securable devices; a set of securable devicecontrollers, wherein each of said securable devices includes a securabledevice controller; a controller user interface in local communicationvia a communications medium with said set of securable devicecontrollers, and configured to: enable a user to initiate access of asecurable device from said set of securable devices; enable the user tosubmit an access indicia to access any one of the securable devices fromsaid set of securable devices; and a controller computing device incommunication with said controller user interface, and configured to:store, in response to receiving the access indicia, the access indiciaindependent of any particular securable device identifier associatedwith the set of securable devices; communicate, via a communicationsnetwork, the access indicia to each of the securable device controllersin said set of securable device controllers; a selected one of saidsecurable devices with an associated securable device controller beingconfigured to: in response to receiving an entered access indicia fromthe user at the selected securable device, verify that the enteredaccess indicia matches the access indicia, and, in response to verifyingthat the entered access indicia matches the access indicia, enable entryof the selected securable device, otherwise, not enable entry of theselected securable device; and communicate the access indicia and asecurable device identifier associated with the selected securabledevice via the communications medium to said controller computing deviceto provision the selected securable device thereby.
 23. The systemaccording to claim 22, wherein said controller computing device, inprovisioning the selected securable device, is further configured to:verify that the access indicia received from the selected securabledevice matches the stored access indicia; in response to verifying amatch: associate the securable device identifier and the access indiciaso as to provision the selected securable device for the user;alternatively, in response to the access indicia received from thesecurable device not matching the stored access indicia, notprovisioning the selected securable device for the user.
 24. The systemaccording to claim 23, wherein said controller computing device isfurther configured to, in response to provisioning the selectedsecurable device for the user, communicate a verification signalindicative of the access indicia received from the selected securabledevice matching the stored access indicia to the securable devicecontroller; and, in response to provisioning the selected securabledevice, communicate a provision rejection signal to the securable devicecontroller to prevent the user from accessing the selected securabledevice.